Artist’s rendering of the Panzerkampfwagen VIII Maus super-heavy tank
The Maus weighed over 200 tons,2 as much as a blue whale. The tank cracked street pavement while moving over it and sank into muddy ground when standing still. Bridges crumbled under its tracks. The tank’s weight afforded its crew safety, wrapping its occupants within a nearly impenetrable, eight-inch thick, welded and cast steel shell. Atop its chassis sat a massive, 128 mm gun,3 adapted from naval artillery. Half as long as a telephone pole, the gun’s barrel fired a huge, 62-pound projectile at nearly three times the speed of sound. Combined with the tank’s armor, the Maus could defend against and destroy anything on a battlefield.
An American Sherman tank landing on a Sicilian beach in 19434
If given the choice, would you choose a massively armored, nearly impenetrable tank that dominated its opponents, or would you choose a lightly armored, under-gunned tank that burned its crew?
The Maus is the better option until you consider its only shortcoming: the Germans never finished building one. Plagued with mechanical issues, poor crew training, and bombarded manufacturing facilities, the terrifying roar of the Maus barely even made a squeak.
Ultimately, the Maus tanks were too complex to assemble and too complicated to maintain. Two hundred tons of complex mechanics require vast amounts of resources and time. When Russian soldiers captured the Maus’ proving grounds, they found only two partially built tanks. Luckily for the Allies, as well as history, the aspirations of German designers were never fully realized.
In contrast, American factories mass-produced the Sherman, churning out nearly 50,000 tanks. So abundant were the tanks that stories5 emerged of eight or more Shermans swarming a single German opponent, surrounding it from all sides, creating a ring of cannon fire. Placed end-to-end, Shermans could encircle the entire capital city of Berlin. Mighty or not, the Maus could not fight math.
Head-to-head, a battle between a single Maus and a single Sherman would certainly favor the Germans. The American tank’s simplicity was both its weakness and its strength, because wars are not won in single tank duels—they are won by design.
What does this decades-old example teach us about design? Complex designs are hard to build and even harder to maintain, be it a World War II tank or tomorrow’s mobile app. No design exists in a vacuum. Each one is affected by all the others, and each one is only a small part of a greater system.
Direct comparisons of competing products lead us into a never-ending arms race of features. Like a pair of dueling tanks, a single comparison may favor a complex solution over a simple one, but we must consider the entirety of a user’s experience to understand which product will ultimately win. Who is our user? What is she attempting to do? When does she do it? How is she currently coping without our product? Why is our solution better than the second-best alternative?
The wreckage of feature-rich products litters software history—Microsoft Bob, Google Lively, iTunes Ping to name but a few.
When we continually add to our creations, we weigh them down with complexity. We create complexity through the act of creation itself. It comes in the form of ideas, budgets, schedules, briefs, proposals, presentations, screens, gestures, web services, repositories, databases, scripts, classes, structures, and bug reports.
We roll out our software and hope it survives among the thousands of other experiences competing for our users’ attention. Yet, complexity obliges us to focus our efforts on the construction and maintenance of the software itself, instead of the experiences it creates. We lose sight of our objectives as we pursue the grand, the expansive, and the robust. Features break. Support fails. Team members leave. Such flare-ups and conflicts divert us from our one true goal: we wish to fulfill a user’s need in the simplest possible way.
Let’s look at three methods to defeat complexity.
Absence
In the story of Adam and Eve, a serpent tempted Eve to take a bite from the forbidden fruit . Eve could have been tempted by any number of distractions, ranging from harp lessons to finding sunblock. Yet, a talking snake grabbed her attention. The snake offered Eve knowledge. Eve accepted, and she and Adam were kicked out of Eden.
From a user experience perspective, we cannot blame Eve. She is our user. Users always crave knowledge, especially when they are tempted by something new and exciting. Think of the countless times you’ve ventured online to buy a gift, only to be derailed by a BuzzFeed article. We could easily blame the snake, but he is only partially to blame. The snake merely directs Eve toward the problem. He is not the problem itself. The problem is the forbidden fruit. Remove the fruit and the problem is solved . Adam and Eve lounge around for eternity, occasionally striking a pose for a Michelangelo fresco.
Like the removal of the forbidden fruit from the Garden of Eden, we, too, can remove a distraction from our creation before it becomes a problem. People will not get themselves in trouble if you take away the opportunity to do so. Applications already do a great deal of work on behalf of users. Users do not need to pick the cell towers through which their calls are routed. They do not need to tell a website to encrypt their passwords . They do not need to translate video game moves into machine code. Why should users need to press a button? Why click a link? Why check a box? Why should users be required to do anything at all? When it comes to software features, absence is underrated.
Reduction
Firefighters burning a control line6
An application with unnecessary features becomes dangerous over time. It withers and takes a spark like a field of dry grass . When we seek limitation, we remove its fuel.
For example, you may learn that users tend to abandon a website’s form halfway through, only filling out five of its ten fields . If you were to remove the one field, you may improve the form’s performance slightly. But if you were to remove five fields, then all the users would complete the form. If an experience stops being successful halfway through it, remove the last half. The quickest way to achieve success is to stop when you find it.
Need to emphasize a message? Shorten it.
Want to increase the number of form submissions? Decrease the number of fields.
Want visitors to email you? Remove your phone number.
Want something to look less expensive? Delete the $ sign before the price .
Addition
The 19th-century Russian writer and playwright Anton Chekhov once instructed, “If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it’s not going to be fired , it shouldn’t be hanging there.” It would serve us well to follow his advice when designing applications.
Asking users a yes-or-no question? Preselect yes.
Need users to choose a date? Set the default date to today.
Want users to share something? Supply the message.
Can your application do something on behalf of the user? If so, do it.
In the correct context, added complexity can improve user experience. It is commonsense. A song composed of a single musical note would grow tiresome. Likewise, unseasoned food is simple, but often unpalatable. Consider the play mechanics of video games . Here, designers add complexity, intentionally obstructing players as they pursue their goals. In Activision’s Call of Duty, a player faces thousands of challenges, ranging from avoiding UAVs to decapitating zombies. Players get shot, crushed, and incinerated. And they welcome it. We can view these complexities as beneficial because the challenges are enjoyable.
So, we can understand our true battle is one where we manage complexity through absence, reduction , and sometimes even addition . Managed complexity has the power to inform and entertain. Unmanaged complexity confuses and distracts. It’s the tank that cannot be built. It’s the forbidden fruit. It’s the field of dry grass . It’s the gun hanging on wall, waiting to be fired at a problem that does not exist.
Key Takeaways
Complex designs are difficult to build and maintain.
Other products and services compete for your users’ time and attentions.
Unnecessary features distract users away from necessary features.
Provide users a default solution and allow users to edit it as needed.
Good UX is more than a summation of features.
Questions to Ask Yourself
What value does an experience provide to a user?
What features can I safely remove from an experience?
What tasks can I do on the behalf of users?